Date: Wed, 6 Apr 94 04:30:22 PDT 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V94 #99 

To: Ham-Digital 


Ham-Digital Digest Wed, 6 Apr 94 Volume 94 : Issue 99 


Today's Topics: 
Baycom TCP/IP Software 
FTP-able copy of AX.25 standard? 
GTOR INFO 
Looking for Wampes docs... 
MFJ 1270C & Netrom 
MFJ 1270C TNC and Host Mode 
Unknown RTTY mode (2 msgs) 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 5 Apr 94 11:59:33 GMT 

From: ncrgw2.ncr.com!ncrhub2!ciss!wtcp!blangos@uunet.uu.net 
Subject: Baycom TCP/IP Software 

To: ham-digital@ucsd.edu 


Is there a driver available for TCP/IP on the Baycom software 
and modem? 


Thanks 

Bruce Langos 

Workstation Products Division F&A 
Bruce.Langos@wtcp.DaytonOH.NCR.COM 
.../uunet!ncrcom!ciss!wtcp!blangos 


Date: 5 Apr 1994 11:38:09 GMT 

From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!xlink.net!news.urz.uni- 
heidelberg.de!rz.uni-karlsruhe.de!rzstud1.rz.uni-karlsruhe.de! 
ukkt@network.ucsd.edu 

Subject: FTP-able copy of AX.25 standard? 

To: ham-digital@ucsd.edu 


Johnny B. (mrmoose@netcom.com) wrote: 
"American Radio Relay League, Inc., AX. 25 Amateur 
Packet-Radio Link-Layer Protocol, Version 2.0, 

: October 1984 (or compatible) ," 


: At any rate, is it around? 

You can get it by email from info@arrl.org. Send a msg with HELP in the 
body of the msg to get information how to use the info-server. 

jochen 


JHAHHAAAH AF Jochen Topf email: ukkt @ rz.uni-karlsruhe.de 
41H Schlehenweg 20 ax25 : DHOGAG @ DBOGE.#SAR.DEU.EU 
JHHHE 76149 Karlsruhe 
WHF = 4HE 0721-756508 
JHHHE <A HREF=http://rzstud1.1rz.uni-karlsruhe.de/jt.html>wW3-Link</A> 


Date: 5 Apr 94 23:28:47 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: GTOR INFO 

To: ham-digital@ucsd.edu 


THE FOLLOWING TEXT WAS PICKED UP FROM THE DL2FAK PACTOR MBX IN GERMANY 
BY VE2FK IN MONTREAL. IT WAS WRITTEN BY DL2FAK, ONE OF THE DEVELOPERS 
OF PACTOR. 


G-TOR - An Improvement? 


G-TOR is a new digital mode, which has been developed by Kantronics. Most of 
its features (like on-line Huffman data compression, link-quality based baud 
rate adjustment, CRC, fundamentals of the packet structure, etc.) are adopted 
from PACTOR. The baud rate used in G-TOR can be 100, 200 or 300 baud. The main 
differences are the use of Golay forward error correction coding with the ob- 
ligatory data interleaving and a hybrid ARQ system. 


The Golay encoding however, as used in the G-TOR mode, is only able to correct 
3 bits in a block of 24 bits and only half of this block (12 bits) carries in- 
formation. The remaining 12 bits have to contain the required redundancy, and 

no new data. It is therefore only possible to correct a few errors despite the 


large overhead. For this reason the Golay encoding would only be useful for 
errors caused by short spikes on the higher short wave frequencies (10 to 20m). 
You cannot however expect it to provide any improvements in typical 80m con- 
ditions. Here it is necessary not only to use hybrid-2 ARQ systems, but also 
suitable, powerful (invertible) codes, which allow the reconstruction of the 
original information, even when only the redundancy block is received, rather 
than Golay or similar simple block coding, which always requires both blocks 
to be received to get the data transferred. 


The most robust HF (short wave), narrow band, data transmission systems known, 
apply very powerful convolutional codes with Viterbi decoding and soft deci- 
sion (requiring an ADC/DSP just like analog Memory-ARQ). The processing speed 
of those systems exceeds the capability of a KAM by factor 100. Despite this 
very expensive approach, they only achieve around 10 dB better weak signal 
performance than PACTOR-1. The closer a system approaches the Shannon boundary 
(theoretical throughput limit) the more difficult it gets to gain another one 
or two decibels. 


WOXI et al claim that they were able to transfer a certain file on the 20m 
band in about 5 minutes using G-TOR, whereas PACTOR, which was used afterwards, 
took about 20 minutes. The conclusion was that G-TOR would be about 4 times 
faster than PACTOR in general, which is actually impossible!! According to the 
system description, G-TOR can on average only be about 1.5 times faster than 
PACTOR. 


The 20m band, which was used for the tests, normally provides a good SNR and 
only very few fluctuations. It is therefore obviously no problem to reach 
higher throughputs, especially when using 300 baud (even short wave Packet 
Radio could have been faster than PACTOR in this case). Also, the comparison 
between PACTOR and G-TOR was based on the PACTOR implementation in the KAM, 
which does not, apparently, provide the full performance anyway, due to the 
different converter and the missing ADC. Since the KAM already uses a modem 
designed for 300 baud operation, it is obvious that G-TOR is favoured. The 
original PACTOR system will still do better than G-TOR on weak signals, as an 
ADC is used in the PACTOR-Controller (PTC) to allow real analog Memory-ARQ. 
To achieve impartial results, you have to transfer the same files containing 
random characters on the typical 80m conditions in G-TOR using two KAMs and 
in PACTOR using two PTCs. The 8.64 characters per second, considered to be the 
typical average throughput of PACTOR, and which led to the conclusion that 
G-TOR would be 4 times faster than PACTOR, are much slower than the average 
rate we obtained with our units. Under even worse conditions we obtained 
around 17 characters per second, depending on the transferred information due 
to the Huffman coding. 


Regardless of the Huffman data compression, which improves the throughput of 
both systems in the same way, the comparison of throughput between PACTOR and 
G-TOR can be easily calculated. According to the protocol description pub- 
lished by WOXI, G-TOR is able to transfer a maximum of 19 characters per se- 


cond when running on 200 baud (They claim 69 data bytes in a cycle duration of 
2.4 seconds at 300 baud, which means maximum 2/3*69/2.4 characters per second 
at 200 baud). The maximum rate of PACTOR at the same speed is 16 chrs/s, which 
is a relationship of 1.18 to 1. The Golay encoding is not able to improve the 
throughput so dramatically that you finally result in a factor 4. It must be 
remembered that the analog Memory-ARQ, as used in the original PACTOR imple- 
mentation, is able to improve the effective signal-noise ratio with each ag- 
gregated packet and hence enables a higher throughput (especially in weak con- 
ditions) than the Golay coding gain. It is therefore obvious that the higher 
maximum throughput of G-TOR is mainly based on its higher maximum baudrate. 
This however means, it has to exceed the usual 500 Hz band width limit. 


With this in mind it must also be remembered that a wider receiver bandwidth 
receives more noise. A 300 baud G-TOR signal will therefore have a poorer S/N 
ratio than a 200 baud PACTOR signal (if they are both of the same fieldstrength 
and the receiver bandwidth is correctly adjusted for both modes). As signals 
decrease, G-TOR would have to switch to 200 baud before the PACTOR signal 

would be affected, thus further reducing some of the proposed speed gain. 


There are still some more disadvantages of G-TOR in comparison to PACTOR, e.g. 
the cycle duration is quite long at 2.4 seconds, and will increase to almost 5 
seconds when using the Golay encoding, hence leading to quite long break-in 
times. The speed adaptation times are necessarily also longer, thus leading to 
poorer results in rapidly changing conditions (multipath). 


Furthermore, the interleaving and the 3 different baud rates used in G-TOR will 
probably lead to a lot of problems with the listen mode, an important point for 
all digital modes used in Amateur Radio. 


Actually G-TOR is just a modified PACTOR system, which probably does not pro- 
vide enough improvement that introducing this mode as another new standard 
would be worth-while. With regard to the basic requirements of each digital 
data transfer mode (like throughput, bandwidth, error rate, etc.) PACTOR al- 
ready represents nearly the optimum attributes that are obtainable with an FSK 
system. A real improvement over the current PACTOR system can only be reached 
when using different modulation schemes like PSK, which require a DSP hardware. 


This step will be done this year with the introduction of PACTOR Level-II. 
Tom Rink, DL2FAK 


via VE2FK 

via WOMFK 

via WTON 

ENJOY, I JUST GOT MY GTOR UPGRADE TODAY, IF YOU WANT TO TEST GTOR LET ME 
KNOW AND I WILL SET THE AMSAT PBBS ON 30 METERS UP FOR GTOR USE. 

YOU CAN CONTACT ME AT 

IN BJARTS@STTTHOMAS. EDU 


PAC. WTON@WBOGDB.#STP.MN.USA.NOAM 


Date: 5 Apr 94 18:29:34 GMT 

From: sdd.hp.com!vixen.cso.uiuc.edu!eagle.sangamon.edu!freeman@hplabs.hp.com 
Subject: Looking for Wampes docs... 

To: ham-digital@ucsd.edu 


Hello, 
I'm looking for any docs on setting up Wampes under Linux. 
The docs with the package consist of one skimpy readme file. 


Thanks, 
Jay 


FEEFEEEEAFELEAFELEEEEEEEFEAEETEEEEEEETEAEETEEEEEEEEEAPEETEEEEEPEE PEATE 


+ Jay Freeman, WT9S Packet: wt9s@w9yci.il.usa.noam + 
+ internet: freeman@eagle.sangamon.edu + 
+ finger for PGP public key. + 


FEEFEEFEEEEFEAFEFEAEEEEEFEAEEFEEEEEEEFEAEETEEEEEEEPEAEETEAEEEPE PEATE 


Date: 5 Apr 94 22:13:33 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: MFJ 1270C & Netrom 

To: ham-digital@ucsd.edu 


> In a previous article, chuckv@comtch.iea.com (Chuck Vyverberg) says: 

> 

> >I saw some messages the last couple fo week giving detailed instructions 
> >on how to get the MFJ1270C TNC to run as a netrom node. 

>> 

> 

> To use the MFJ1270C with netrom or TheNET, all you need to do is program 
> a 27256 EPROM with the modified firmware module (V2.08B is the one I have 
> in three digi's in central IL) and plug it in. No circuit mods are 

> required. 

> 

> Installing an X1J node is another matter... 

> 

> 73, Drew 

> 

> -- 

> ken eee k------------------------------------- * 

> 


| Andrew B. White K9CW | internet: k9cw@prairienet.org 


> | ABW Associates, Ltd. | phone/fax: 217-643-7327 
So soe ete esas eee Stet eases Fees ste setae te eee le tet eee tees * 


Yes there is a mod required to use the C version of the tnc with TheNet or 
X1J. Here's a copy of the message that went around about it. 


Bill N8KHN 
healy@moriah.ee.unr.edu 


X1/TheNET mods for MFJ-1270C 


From: WBOYRQ@NFON.#NENE.NE.USA.NA 
To : INFO@ALLUS 


WBOYRQ @ NFON.#nene.ne.usa.na /TPK 1.81 Msg #:751 Date:02-01-80 
Time:9:56Z 


To modify the MFJ-1270C for use with X1J/Thenet EPROMS follow 
these instructions: 


You must complete all of these steps in order for Netrom firmware 
to function. 


NOTE: if you are not using X1J firmware skip the first step and make 
sure that JP15 is set for 256k. 


Step 1: Bend pin 1 of 27c512 out so it will not touch socket, then 
jumper pin 1 of 27c512 to pin 8 of MODEM header J4. (see X1J docs) 


Step 2: Remove U4Q. Add jumper from pin 16 to pin 1 (ground pin 16) 
A 
[I think this should be 10 (gnd)] 
Step 3: Remove JMP9 altogether (no jumper on any pins) 
Step 4: Cut JMPX "PAD" to prevent node from hearing itself 


Step 5: Add 1000hm resistors to R14 and R15 if not already in place. 


This information came directly from MFJ and I have used it successfully. 

Hope this helps you. 
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD? 
3 IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM; 63 
3 : [[221100 73's de Al WBOYRQ @ NFON.#NENE.NE.USA.NA 001122[[ : 3 
3 : [[221100 Akron, Iowa. 712-568-2810 GRID <EN12RT> 001122[[ : 3 
3: [[221100 TCP/IP 44.50.2.6 001122[[ : 3 


3: [[221100 Internet: SCHEMMERAL@BVC.EDU 001122[[ : 3 
3 HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM< = 3 
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY 


Date: 5 Apr 94 22:29:53 GMT 

From: sdd.hp.com!saimiri.primate.wisc.edu!news.doit.wisc.edu!news@hplabs.hp.com 
Subject: MFJ 1270C TNC and Host Mode 

To: ham-digital@ucsd.edu 


I've been looking through my TNC documentation, and the only reference I find to 
host mode mentions that documentation is available on diskette, but no command is 
given for putting the TNC into host mode. 


Can anyone help? 


73, Tom N9UDL 


Date: Tue, 5 Apr 1994 20:05:39 GMT 

From: ihnp4.ucsd.edu!swrinde! gatech!newsxfer.itd.umich.edu!nntp.cs.ubc.ca!alberta! 
quartz.ucs.ualberta.ca!kakwa.ucs.ualberta.ca!gov.nt.ca!ve8ev@network.ucsd.edu 
Subject: Unknown RTTY mode 

To: ham-digital@ucsd.edu 


Keywords: teletype RTTY digital signal identification 


In regards to the questions on RTTY signals on the SW bands: 

There are hundreds of different FSK modes in use by government and 
commercial HF stations worldwide. 95% of these are encrypted so that 
they cannot be decoded without the proper key (usually some form of bit 
inversion). In addition to the coded signals, there are also stations 
using odd speeds and shifts and stations transmitting non-roman text, 
ie, chinese, korean, etc. If you are interested in decoding some of these 
transmissions, Universal Radio makes several high end digital decoders 
which can probably decode a large percentage of what is out there. 

73 

John Boudreau 

ve8ev@inukshuk.gov.nt.ca 


Date: Tue, 5 Apr 1994 16:22:10 +0000 


From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!pipex!demon!isis.demon.co.uk! 
ian@network.ucsd.edu 

Subject: Unknown RTTY mode 

To: ham-digital@ucsd.edu 


In article <CnqtAu.4q@sunsrvr6.cci.com> jdc@cci.com "James D. Cronin" writes: 


>I have also run into these signals. I always thought the inability 
>to decode them was due to shortcomings in hardware interface and 
>software. (I use Hamcom 2.2 with the 741 op-amp interface.) But 
>this may not be the case. 

> 

>After receiving the last half of a weather-fax map, the station switched 
>to RTTY. It was strong signal, and the weather-fax came in OK. After 
>it switched to RTTY I fired up Hamcom 2.2. It was easy to figure out 
>frequency shift and baud rate with the "Spectrum" and "Bit length" 
>screens. But the text was undeciperable gobbledygook. 

> 

>Seems like it must be some type of maritime-related station. Anybody 
>have more specific info? 


Are you sure that Hamcom isn't just letter shifting ? A lot of weather 
related RTTY is almost purely numeric. Most decoders will tend to assume 
that they've missed a letter shift and just switch modes after a few 
numbers. From then on it is gobbledygook. You can switch off the automatic 
shift. 


Regards 
Tan. 
| Ian Smith | "The Moving Finger writes; 
| ian@isis.demon.co.uk | and, having writ, Moves on." 


Date: 5 Apr 1994 17:41:22 GMT 

From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!pipex!sunic!psinntp!psinntp! 
news .mentorg.com! hpbab33.mentorg.com!wv.mentorg.com!hanko@network.ucsd.edu 
To: ham-digital@ucsd.edu 


References <2na50c$bsl@network.ucsd.edu>, <2nfd1m$11k@hpbab.mentorg.com>, 
<1994Apr1.102339.15324@hemlock.cray.com>2a 

Reply-To : Hank_Oredson@mentorg.com 

Subject : Re: [REPOST] The # in PBBS addresses.... 


In article <1994Apr1.102339.15324@hemlock.cray.com>, andyw@aspen32.cray.com (Andy 
Warner) writes: 


|> 

|> In article <2nfdlm$11k@hpbab.mentorg.com>, hanko@wv.mentorg.com (Hank Oredson) 
writes: 

[Foes 

|> > Or is there some magic required of the subdomains of .ampr.org 

|> > that is not required of other .org subdomains? 

|> 

|> Maybe some semblance of responsibility - it sounds like you want 

|> to hide an ad hoc network behind a "correctly implemented" 

|> (in internet terms) one, without having to to actually change 

|> anything. This is a two way street, if you want the "advantages" 

|> offered by high connectivity, you may need to change a few things 

|> (and - gasp - admit some things were badly thought out, or badly 

|> implemented..). Fidonet seem to have grasped that point years ago.... 
|> 

|> Of course, folks can always retreat into the "why would we ever 

|> want to connect to anyone else" mindset, the last bastion of 

|> people who see their empire crumbling... 


This is the third try. 


Thus far, the responses have only been "The way it is done now is wrong." 
This is from at least three avowed "networking experts." 


However, "It is wrong" is useless information. 
We all perfectly willing to agree that it is wrong. 


I have been attempting to get answers to a different question, let me try it 
again. 


"What should we do so it is done right?" 


So far, nobody has posted any useful response to this question. 


Can you explain what you meant by . ad hoc network..." and give examples 
of "non-ad hoc networks"? This might be helpful information. 


Long ago and far away (when this packet stuff all started) several of us 
asked the same question, and go much the same answers we are getting now: 
"No No No, you are DOING IT ALL WRONG". We got tired of this and simply 
went ahead and defined our own subdomains of ampr.org. 


Again, we have the same response from the "networking gurus", but a total 
lack of useful information. 


If indeed "we got it all wrong", what should we do to fix that? 


Waiting with ‘bated breath for an educational reply ... 


Hank 


Hank Oredson @ Mentor Graphics 
Internet : hank_oredson@mentorg.com 
Amateur Radio: WORLI@WORLI.OR.USA.NOAM 


End of Ham-Digital Digest V94 #99 
KAKKKKKKKKKKKKKKKKKKKKKKKEKR KKH 


